昨天我把一次 AI 請求經過的 Web/API、Database、Embedding、Vector Store 與 LLM Serving 拆開，也標出共用的 Host、Storage 和 Network。

但畫完 dependency map 之後，我還是無法回答一個問題：

服務到底要慢到什麼程度，我才應該認定已經不可用？

如果沒有先回答這題，我可以把 Prometheus、Grafana 與 GPU metrics 都裝好，最後卻還是只能凭感覺說「看起來好像很慢」。所以今天我先不選監控工具，而是先定義哪些使用者請求算好，哪些算壞。

SLI 不是「我收得到的所有數字」

剛開始列指標時，我很容易把 GPU utilization、VRAM、CPU、RAM、queue length 全部當成 SLI。但這些數字主要用來解釋原因，不是使用者要得到的結果。

使用者真正在意的是：

• 請求有沒有成功。
• 送出後多久看到第一個 token。
• 回答是不是在可接受的時間內完成。
• 回答過程有沒有中斷。

所以我把指標分成兩層：

這個區分很重要。GPU utilization 可能很高，但每一次請求仍然在目標時間內完成；反過來，GPU utilization 看起來不高，使用者也可能因為 queue、Storage 或其他相依服務而一直等待。

先定義「好請求」，才有分母

Google SRE Workbook 建議把 SLI 寫成好事件數除以總事件數。公式很簡單，難的是分子和分母到底包含什麼。

SLI = good events / eligible events

我先為「互動式短回答」這一類 workload 定義 eligible event：

1. API 已接受請求。
2. 請求通過格式驗證。
3. 使用者並未主動取消。
4. 請求屬於同一個服務級別，不把 batch job 和互動式請求混在一起。

已接受後的 timeout、HTTP 5xx、無輸出或中途中斷，都必須留在分母裡。如果把失敗請求從分母排除，成功率就只是一個被修飾過的數字。

我先為公開參考 workload 寫一份暫定 SLO

以下數字是公開參考 workload 的起點，是目標，不是實測成績。Day 04 才會用固定模型、輸入和輸出長度建立 baseline，再判斷這些目標是否合理。

寫進可版本化的 policy，而不是只留在文章或 dashboard 標題上：

{
  "policy_status": "draft",
  "workload_class": "interactive-short",
  "window_days": 28,
  "availability": {"target_ratio": 0.99},
  "ttft": {"target_ratio": 0.95, "threshold_ms": 5000},
  "end_to_end": {"target_ratio": 0.95, "threshold_ms": 30000},
  "queue_wait": {"target_ratio": 0.95, "threshold_ms": 2000}
}

檔案已放在 configs/day03-slo-policy.json。draft 代表已經能被計算，但還不應當成對外承諾。

我先用 synthetic events 檢查公式，不當成平台成績

我準備了 10 筆不含 prompt、response、帳號或環境資訊的 synthetic request events，先確認分母、取消排除與 threshold 計算方式沒有寫反。

python3 labs/sre/evaluate_slo.py

這組資料有 10 筆請求，其中 1 筆是使用者主動取消，所以 eligible requests 是 9。計算結果中，availability 是 8/9，TTFT 與 queue wait 都是 7/9，四個目標全部顯示 met: false。

這個結果不是在說平台不合格，而是暴露另一個問題：九筆請求太少，99% SLO 在整數事件上連一次失敗都容不下。小樣本可以驗證計算邏輯，卻不適合判斷 28 天 SLO 是否達標。

我因此把「公式有沒有正確」和「平台有沒有達標」分開。前者今天就能用 synthetic data 檢查；後者必須等固定 workload 的代表性數據累積後才有意義。

Error budget 要用來做決策，不是只拿來報數字

如果 availability SLO 是 99%，在 10,000 筆 eligible requests 的觀測窗口中，error budget 是 100 筆壞事件。

10,000 × (1 - 0.99) = 100

但這個 100 不只是月報上的數字。如果一次變更快速消耗剩餘 budget，我要有一個預先同意的動作，例如停止增加新功能、回滾變更，或把工程時間優先投入可靠性。沒有對應決策的 error budget，很容易退化成另一個 KPI。

這一天我刻意還沒有定義告警

告警是後面的事。今天如果就直接寫「GPU 高於 90% 就通知」，我仍然不知道使用者有沒有受影響。

我會等 Day 04 取得 baseline，知道正常狀態的 TTFT、P50、P95、throughput 與資源訊號後，再開始設計 burn-rate alert。到那時，告警才能回答「SLO 正在多快被消耗」，而不是單純告訴我某個儀表數字變大。

今天的結論

今天我先把「好請求」和分母寫清楚，才定義暫定 SLO。這也讓我確認，GPU、VRAM、CPU 與 queue 的診斷訊號很重要；平台有沒有提供可接受的服務，還是要回到使用者請求來判斷。

下一篇會固定模型、輸入、輸出上限與併發條件，建立第一份可重跑的 baseline。到時我要回答的不是「這台機器快不快」，而是：

在哪一組固定條件下，這個平台的服務品質落在哪裡？

下一篇：Day 04｜建立 Baseline：目前這台 AI 平台到底有多快

操作交接

需要代為收集匿名 request events 或重跑 SLI 計算時，請使用 docs/day03-operations/01-it-operation-sli-slo.md。文章內不放個人電腦、主機或內部服務配置。

參考資料

1. Google SRE Workbook, Implementing SLOs
2. Google SRE, Service Level Objectives
3. Prometheus Documentation, Histograms and summaries

內文的 10 筆 request events 為 synthetic data，只用來檢查計算邏輯，不是任何實際平台的效能成績。